One of the current changes is how we handled injecting/registering services from clients. I also want to discuss more about how we handle/register events and try to move away from scanning method names for events.

Draft for now as we work this out.

As this refactor evolved, so did the systems relying on it. I did my best to keep the changes within the three big systems (PluginManager, CommandHandler and EventDispatcher).

And since I'm approaching the end of this refactor, I'd like to add the most major changes to the various systems (Events and Commands).

PluginManager

The entire class and a majority of the things that relied on it have changed.
Here's moreso a list of things that changed.

• A service collection was created for plugins
• Each plugin container gets a scope of that service collection and is disposed when the plugin is disposed.
• Plugins have two new methods "ConfigureServices" and "ConfigureRegistry"
• All reflection methods were removed from PluginBase
• PluginDependency was removed in favor of the shared ServiceCollection
• PluginInfo is now scanned and populated from a plugin.json embedded resource. Sample Plugin

When plugins are "handled" (e.x loaded and reloaded), two methods will be called. "ConfigureServices" and "ConfigureRegistry".

ConfigureServices

Is, as the name explains, configuring services. These services will be added to a shared service collection and will be turned into a scope service provider for every plugin when the server is fully loaded.

ConfigureRegistry

Isn't as self-explanatory, at least to those unfamiliar with any type of Minecraft modding. This method is used for registering commands, events, and eventually items, blocks, entities, biomes, dimensions, and many more. And it gets called after ConfigureRegistry.

ObjectMethodExecutor

This Post explains best why I decided to bring this in. But both EventDispatcher and CommandHandler use ObjectMethodExecutor.

The Command Framework

The way commands are stored and executed has changed, while the system itself is more or less the same (finding and registering). Any problems we had before with commands, at least with my current testing, are not present anymore. We now support registering a "minimal API" way of registering commands as well.

registry.MapCommand("test", 
    [CommandInfo("test command")]
    async (CommandContext ctx, int number, int otherNumber) =>
    {
        await ctx.Player.SendMessageAsync("Test #{number} and #{otherNumber}. This command was executed from the MinimalAPI.");
    });

Attributes and parameters are found and are read accordingly by the framework. You're not able to register command groups yet through this API, but I do plan on adding it in the future.

The way to register command modules has also changed a bit. You no longer need to provide a CommandContext parameter in your command methods as it is included as a property in the new CommandModuleBase abstract class, which all your commands should inherit from. Dependency injection works normally, either through the inject attribute or through constructors and eventually parameter injection. These classes have a scoped lifetime.

public class MyCommands : CommandModuleBase
{
    [Inject]
    public ILogger<MyCommands> Logger { get; set; }

    [Command("mycommand")]
    [CommandInfo("woop dee doo this command is from a plugin")]
    public async Task MyCommandAsync()
    {
        Logger.LogInformation("Testing Services as injected dependency");
        await this.Player.SendMessageAsync("Hello from plugin command!");
    }
}

Command Handler Internals a few things changed with this but not a lot.

The Event System

The way events are stored and executed has changed, but not by a lot. Instead of scanning method names to try and match them to current events and then registering them through the traditional event subscription model, we are now checking the first parameter of the event and then adding that method to a list of executors stored in a dictionary stored by event names if it is a valid event type. The executors are then executed in ASC order of priority.

And as registering commands has a similar "minimal API" approach, so do events.

registry.MapEvent((IncomingChatMessageEventArgs chat) =>
{
    this.Logger.LogDebug("Got a chat message! From MinimalAPI event.");
});

The way to register event handlers is simple. Inherit from the MinecraftEventHandler abstract class, and the PluginManager will scan and store these for you. Dependency injection works normally, either through the inject attribute or through constructors and eventually parameter injection. These classes have a scoped lifetime as well.

public class MyEventHandler : MinecraftEventHandler
{
    [Inject]
    public ILogger<MyEventHandler> Logger { get; set; }

    [EventPriority(Priority = Priority.Critical)]
    public async ValueTask ChatEvent(IncomingChatMessageEventArgs args)
    {
        Logger.LogInformation("Wow a message through the event handler class!");
        await args.Player.SendMessageAsync("I got your chat message through the event handler class!");
    }
}

Here's the internals

Final stuff thingys

hopefully this will set the path for future implementations and ease up a lot of pain introduced by the old implementations.